What the bug is

In content/academy/japan/evaluate.mdx (lines 197–222), the call site renders:

<ManualGuideList
  locale="ja"
  title="その他のガイド"
  guides={[ ... ]}
/>

But components/academy/ManualGuideList.tsx defines its props as { title?: string; guides: ManualGuideListItem[] } and its body destructures only { title = "Guides", guides }. React silently ignores unknown props on functional/non-DOM components, so locale="ja" is dead code — it never reaches any rendering logic.

Why it doesn't blow up today

The component currently has nothing locale-dependent that the caller doesn't already control:

• title is explicitly overridden to "その他のガイド", so the default English "Guides" never appears.
• Each GuideRow renders caller-provided topic/lede strings verbatim — those are already Japanese in the guides array.

So visually the output is identical with or without locale="ja". Functional impact today: zero.

Why it still matters

This PR threads a locale prop through nine other Academy components (LoopDiagram, ManualGuideCallout, AgentPromptCallout, DatasetFieldsDiagram, ErrorAnalysisProcessDiagram, EvaluationEvolutionDiagram, LoopSubset, RagTraceViewDiagram, TracingHierarchyDiagram) — and in all of those the prop actually does something. A reader scanning this MDX would reasonably assume locale="ja" here also has effect, and a future contributor adding a localizable string to ManualGuideList (e.g. a default "More guides" ribbon) would silently inherit a broken locale wire-up.

Step-by-step proof

1. Author writes <ManualGuideList locale="ja" title="その他のガイド" guides={...}/> in evaluate.mdx.
2. MDX compiles this to React.createElement(ManualGuideList, { locale: "ja", title: "その他のガイド", guides: [...] }).
3. ManualGuideList is defined as function ManualGuideList({ title = "Guides", guides }: ManualGuideListProps) — only title and guides are destructured.
4. JavaScript destructuring ignores any extra keys on the props object, so locale is never read.
5. ManualGuideList does not spread ...rest onto a DOM node or pass props through anywhere, so React never warns about an unknown DOM attribute either.
6. The component renders identically whether locale="ja" is present or absent.

How to fix

Two equally valid options, depending on whether ManualGuideList is expected to grow locale-aware strings later:

• Drop the prop (smallest change): remove locale="ja" from the MDX call site in evaluate.mdx. title is already explicitly localized.
• Extend the component (matches the rest of the PR): add locale?: string to ManualGuideListProps, destructure it, and use it for the default ribbon label (e.g. title = locale === "ja" ? "ガイド" : "Guides") — mirroring how ManualGuideCallout localizes its ribbonPrefix and ctaText.

Severity: nit — cleanup/consistency, no current user-visible defect.

What the bug is. This PR introduces a locale-aware steps array (const steps = locale === "ja" ? STEPS_JA : STEPS) and correctly switches the .map call at line 105 from STEPS.map to steps.map. However, the connector guard immediately below at line 120 still reads {i < STEPS.length - 1 && ...}, referencing the English-only STEPS constant rather than the locale-selected steps array.

Why it's latent today. STEPS and STEPS_JA each contain exactly 5 entries, so STEPS.length === steps.length for every supported locale and the rendered output is identical to using steps.length. No user will see a visual defect on this PR as it stands — this is purely a code-quality / consistency issue.

Why it still matters. The diff introduced steps precisely to abstract over locale, and one of the two sites that needs it was missed. The inconsistency is a footgun for future contributors: if someone adds or removes a step from STEPS_JA (or adds a third locale array, e.g. STEPS_DE) and forgets to make a matching edit to STEPS, the connector count will no longer match the rendered step count — producing either an orphan trailing connector or a missing connector between the last two cards.

Step-by-step proof. Suppose a future contributor adds a 6th step to STEPS_JA:

1. steps = STEPS_JA now has length 6.
2. The .map at line 105 renders 6 step cards (indices i=0..5).
3. The guard at line 120 evaluates i < STEPS.length - 1, i.e. i < 4 (because STEPS.length is still 5).
4. Connectors are rendered for i=0,1,2,3 — only 4 connectors between 6 cards.
5. The 5th and 6th cards have no connector between them. Conversely, if a step is removed from STEPS while STEPS_JA keeps 5, an extra connector renders past the last card.

How to fix. Change STEPS.length to steps.length on line 120 so the guard derives from the same array being iterated. This is the same one-line change Greptile-style reviewers would call out — defensive, consistent with the abstraction the diff introduced.